1. Field of Invention
This invention pertains to distributed or replicated databases, and particularly to the locking of access to data objects maintained by such databases.
2. Related Art and Other Considerations
When executing application programs, computers frequently assign and/or change values of data objects. In many instances the data objects are stored as part of a database. In more complex systems in which a plurality of computers are networked together, more than one computer may require access to a certain data object, and may change or update the value of that data object. To cater to such a multi-computer networked environment, a replicated database system can be established. In a replicated database system, each computer can maintain its own version of the database so long as all other computers are advised of the changes of a data object for maintaining consistency among the replicated databases.
Replicated databases have two primary advantages. A first advantage is fault tolerance. A second advantage is that local access to a replicated database is faster and less expensive than remote access to a database at another computer.
Each computer can have a plurality of application programs or processes accessing its local version of a replicated database. When a particular process needs to access a local version of the replicated database, a "lock" of the data object must be obtained by the accessing process in order to ensure exclusive access to the data object. Many so-called "concurrency control" algorithms or strategies use various forms of locking to achieve this goal.
The problem with locking of data objects in a network context is the increased effort and traffic occasioned by generating and handling lock-related messages between various nodes of the network. Consider, for example, a multi-node network which includes nodes N1 and N2, each having a computer which executes many processes and a local version of a replicated database in which resides data object Y. The computer of each node has a special purpose process known as a lock manager for administering the setting and releasing of locks for data objects including object Y. When a first process of node N1 desires access to data object Y, the computer of node N1, on behalf of the first process of node N1, sends a lock request message to the lock managers of all nodes of the network having data object Y in their versions of the replicated database. In response, each node in the network returns a lock status message to node N1, e.g., confirming (when appropriate) that data object Y is now locked at node N1. The first process of node N1 then can access and (when necessary) modify the value for data object Y. When the first process is finished with data object Y, the computer of node N1 on behalf of its first process sends a lock release message to all nodes. If a second process at node N1 then desires access to data object Y, essentially the same steps as described are executed, including issuance of the lock request message, collecting of response messages, and (upon completion of usage of data object Y) issuance of lock release messages.
Thus, repeated requests by processes at the same node for locking a data object can entail considerable message traffic over the network, as well as complicated lock bookkeeping by lock managers situated throughout the network. Various strategies to counter these undesirable ramifications have been developed, as explained, for example, by Bernstein, P. A., et al., Concurrency Control and Recovery In Database Sytems, Addison Wesley, 1987; and Ozsu, T., Valduriez, P., Principles of Distributed Database Systems, Prentice Hall, 1991.
One strategy is merely to ignore the overhead associated with network input/output when setting locks on remote objects. A second strategy is to organize the data as having one primary copy and a set of secondary copies. With such organization, the secondary copies are not visible to the programs or processes accessing the data. The secondary copies are updated by the system whenever the primary copy is updated. The major disadvantage of this second strategy is that the system becomes static. All programs are forced to use the primary copy and, if the primary copy fails, or if for any reason one of the secondary copies wants to act as the primary copy, the system must be reconfigured.
A third strategy is to employ a loose or non-existent locking in which multiple copies can be updated simultaneously without prior locking. This third strategy works primarily in certain peculiar situation, e.g., when different operations on the same data object commute. For example, if an integer value is stored, and the only operation allowed on the data object is incrementation, i.e., a counter, locking is not necessary.
What is needed therefore, and an object of the present invention, is simplified method and apparatus for locking access to data objects of a database which is replicated across a network.